Protocols for connecting intelligent service modules in a storage area network

ABSTRACT

Implementations are disclosed that provide protocols for connecting an intelligent service module within a storage area network (SAN). The protocols support physical connections between the intelligent service module and a director-level switch of the SAN. In some variations, the intelligent service module may comprise a director service module (DSM), a domain-sharing leaf switch service module (LSSM), or a non-domain-sharing LSSM. The protocols provide for establishing link parameters and negotiating responsibilities between the intelligent service module and the director-level switch. In one configuration, for example, ELP and ELP_ACCEPT frames may be used to establish the link parameters. In another configuration, ESC and ESC_ACCEPT frames may be used to negotiate responsibilities between the intelligent service module and the director-level switch. Other configurations also provide an ownership status of the intelligent service module that is used to determine whether the switch can initiate management of the intelligent service module.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of pending U.S. patent applicationSer. No. 13/097,515 entitled “Protocols for Connecting IntelligentService Modules in a Storage Device Area Network” filed on Apr. 29,2011, which is a continuation of U.S. patent application Ser. No.11/386,379 entitled “Protocols for Connecting Intelligent ServiceModules in a Storage Device Area Network” filed on Mar. 22, 2006, nowU.S. Pat. No. 7,953,866, and related to pending U.S. patent applicationSer. No. 11/239,954 entitled “Federated Management of IntelligentService Modules” by Joseph Chamdani et al. filed on Sep. 29, 2005, andU.S. Ser. No. 11/216,903 entitled “Management of a Switch Fabric ThroughFunctionality Conservation” and filed by Jesse B. Willeke et al. on Aug.31, 2005, all of which are hereby incorporated into this application byreference in their entirety.

TECHNICAL FIELD

The invention relates generally to storage area networks, and moreparticularly to protocols for connecting intelligent service modules ina storage area network.

BACKGROUND

A storage area network (SAN) may be implemented as a high-speed, specialpurpose network that interconnects different kinds of data storagedevices with associated data servers on behalf of a large network ofusers. Typically, a storage area network includes high-performanceswitches as part of the overall network of computing resources for anenterprise. The storage area network is usually clustered in closegeographical proximity to other computing resources, such as mainframecomputers, but may also extend to remote locations for backup andarchival storage using wide area network carrier technologies. FibreChannel networking is typically used in SANs although othercommunications technologies may also be employed, including Ethernet andIP-based storage networking standards (e.g., iSCSI, FCIP (Fibre Channelover IP), etc.).

In one configuration, switches are assembled in a chassis using aselection of blade components of a SAN switch. Individual bladecomponents are fitted into slots in the chassis and connected to achassis backplane for interconnectivity. For example, line card blades,switch blades, and other blade components can be inserted into a chassisto provide a scalable and customizable storage network switchconfiguration. Typically, the blades are controlled by shared controlprocessors (e.g., one active and one backup), powered by one or moreshared power supplies through the backplane, and cooled by a shared setof cooling fan trays.

Fabric-based intelligent services, such as routing, virtualization, anddistance services, may be added to a switch to enhance the performance,scalability, and features of the switch. For example, a wide areaconnectivity service blade can be inserted into an open slot in thechassis to provide Fibre Channel over IP bridging. In this fashion, theintelligent services can be managed as part of the switch.

However, adding such services as blades in a chassis presentssignificant limitations. A chassis has a limited number of slots, and aSAN administrator may not have an open slot in which to add anintelligent service blade. Even with an available slot, a service bladeadds additional risk to the core switch, reducing the overallmean-time-between-failures (MTBF). Further, intelligent service bladestend to run hotter than core switch blades and therefore requireplacement in the better-cooled slots in the chassis. A chassis backplanealso has power and signaling constraints that can restrict thescalability of a switch, particularly when an intelligent services bladeis added to the chassis.

SUMMARY

Implementations described and claimed herein address the foregoingproblems by providing protocols for connecting an intelligent servicemodule within a storage area network (SAN). The protocols supportphysical connections between the intelligent service module and adirector-level switch of the SAN. In some variations, the intelligentservice module may comprise a director service module (DSM), adomain-sharing leaf switch service module (LSSM), or anon-domain-sharing LSSM. The protocols provide for establishing linkparameters and negotiating responsibilities between the intelligentservice module and the director-level switch. In one configuration, forexample, ELP and ELP_ACCEPT frames may be used to establish the linkparameters. In another configuration, ESC and ESC_ACCEPT frames may beused to negotiate responsibilities between the intelligent servicemodule and the director-level switch. Other configurations also providean ownership status of the intelligent service module that is used todetermine whether the switch can initiate management of the intelligentservice module.

In some implementations, articles of manufacture are provided ascomputer program products. One implementation of a computer programproduct provides a computer program storage medium readable by acomputer system and encoding a computer program. Exemplary storage mediamay include without limitation magnetic and optical disks, EEPROMS,flash memory, RAM, and other storage devices.

Other implementations are also described and recited herein.

BRIEF DESCRIPTIONS OF THE DRAWINGS

FIG. 1 illustrates an exemplary computing and storage frameworkincluding a local area network (LAN) and a storage area network (SAN).

FIG. 2 illustrates exemplary intelligent service modules connected to achassis-based director-level switch.

FIG. 3 illustrates an exemplary exchange of information between adirector-level switch and an intelligent service module to establish aphysical connection between the switch and the module.

FIGS. 4A and 4B illustrate an exemplary method of establishing aphysical connection between a director-level switch and an intelligentservice module.

DETAILED DESCRIPTIONS

The use of intelligent service modules in a storage area network bringsa combination of new management concepts and capabilities to traditionalswitching products. Intelligent service modules can be located externalto a switch chassis and communicate with the switch components in thechassis via an external cable using a communications transport mechanismbetween the switch components and the intelligent service modules. Inone implementation, for example, IPFC (Internet Protocol over FibreChannel) is employed as the transport mechanism between a switch and anintelligent service module. The intelligent service module is cabled toa switch through Fibre Channel ports in each device, such that thecommunications between the intelligent service module and the portmodule are “in-band” communications relative to the data communicationsof the switching network.

Each intelligent service module can be managed within the same logicaldomain as the switch (i.e., domain-sharing) or may be managedindependently from the switch (i.e., non-domain-sharing). In adomain-sharing configuration, for example, the switch can handle much ofthe management of the intelligent service module and otherwise forwardsmanagement communications received by the switch from the managementsoftware to the intelligent service module. Domain-sharing alsoconserves Domain IDs, allows the intelligent service module to appear asa logical part of the switch in which the module's ports are anextension of the switch ports, and reduces fabric-wide disruptions whenan intelligent service module is added to or removed from the director.Likewise, an intelligent service module can be managed in-band orout-of-band from the switch. Where the intelligent service module ismanaged in-band, for example, a traditional physical Ethernet (i.e.,out-of-band) connection between management software and each intelligentservice module can be omitted.

Generally, a switching fabric involves a collection of interconnectedswitches that are capable of communicating among them. In contrast, aSAN can comprise one or more fabrics.

FIG. 1 illustrates an exemplary computing and storage framework 100including a local area network (LAN) 102 and a storage area network(SAN) 104. Various application clients 106 are networked to applicationservers 108 and 109 via the LAN 102. Users can access applicationsresident on the application servers 108 and 109 through the applicationclients 106. The applications may depend on data (e.g., an emaildatabase) stored at one or more of the application data storage devices110. Accordingly, the SAN 104 provides connectivity between theapplication servers 108 and 109 and the application data storage devices110 to allow the applications to access the data they need to operate.It should be understood that a wide area network (WAN) may also beincluded on either side of the application servers 108 and 109 (i.e.,either combined with the LAN 102 or combined with the SAN 104).

With the SAN 104, one or more switches 112 provide connectivity, routingand other SAN functionality. Some such switches 112 may be configured asa set of blade components inserted into a chassis or as rackable orstackable modules. The chassis has a back plane or mid-plane into whichthe various blade components, such as switching blades and controlprocessor blades, may be inserted. Rackable or stackable modules may beinterconnected using discrete connections, such as individual or bundledcabling.

In the illustration of FIG. 1, at least one switch 112 is coupled to atleast one external intelligent service module. Rather than beinginserted into an open slot in the switch chassis, the intelligentservice module is connected to the switch 112 via an optical or wiredcable. The intelligent service module can nevertheless be managed withinthe same logical domain as the switch without the need for a separateout-of-band connection. In addition, the intelligent service module canbe “attached” or added to the switch without disrupting operation of theswitch (e.g., to move blades or make chassis slots available).

FIG. 2 illustrates exemplary multiple intelligent service modules 200,202, 204, and 206 connected to a chassis-based director-level switch208. Fibre Channel ports of each intelligent service module 200, 202,204, and 206 are coupled to Fibre Channel ports in the switch 208 viaoptical cabling 210 (although wired cabling, such as copper cabling, mayalternatively be employed). In the configuration shown in FIG. 2, theintelligent service modules 200, 202, 204, and 206, are external to thedirector-level switch 208 and do not directly consume port slots of theswitch 208 or the bandwidth dedicated to those slots. Each illustratedintelligent service module also has separate power supplies and coolingmechanisms, although individual intelligent service modules may sharepower supplies and/or cooling mechanisms in alternative configurations.

A management client 212 is connected to the switch 208 via an Ethernetconnection. The management client 212 provides user control andmonitoring of various aspects of the switch and attached devices,including without limitation, zoning, security, firmware, routing,addressing, etc. The management client 212 may identify the managedswitch 208 using a domain ID specific to the switch or, in adomain-sharing configuration, a domain ID shared with one or more of theattached intelligent service modules 200, 202, 204, and 206. Inaddition, the management client 212 may identify the managed switchusing a World Wide Name (WWN) or an IP address. In cases where a switchimplements multiple virtual fabrics, the management client may use morethan one domain ID in its communications with the switch. The managementclient 212 therefore can send a management request referencing thedomain ID of the switch, an intelligent service module identifier, and aport identifier of an attached intelligent service module, and theswitch will perform whatever portion of the requested managementfunction it is capable of performing (if any) and forward instructionsto the intelligent service module possessing the referenced port foradditional activity, if necessary.

Despite being external from the chassis, the intelligent service modules200, 202, 204, and 206 may be configured to be managed within the samelogical domain 214 as the director-level switch 208 (i.e., share thedomain ID of the director-level switch 208) or may be assigned a domainID independent from the ID assigned to the switch 208. Each intelligentservice module may also be configured to be independently managed or toutilize federated management by the switch 208. In one configuration ofa SAN, for example, a director services module (DSM) supportsdomain-sharing with the switch 208 and federated management by theswitch. A leaf switch services module (LSSM), alternatively, is managedindependently by from the switch. An LSSM, however, may supportdomain-sharing with the switch (i.e., a domain-sharing LSSM) or maysupport independent domain IDs than the ID assigned to the switch 208(i.e., a non-domain-sharing LSSM). An LSSM may share domain IDs (e.g.,proxy IDs) with other LSSMs to conserve domain IDs within the fabriceven if they do not share domain IDs with the switch 208.

In order to support these states, one configuration of a Fibre Channelinter-switch link (ISL) connection may comprise a port state thatsupports domain-sharing (e.g., a “D_Port state”) between thedirector-level switch 208 and one of the intelligent service modules200, 202, 204, and 206 and an alternative port state that does notsupport domain sharing between the director-level switch 208 and one ofthe intelligent service modules 200, 202, 204, and 206 (e.g., an “E_Portstate”). A DSM, for example, would be coupled to the switch 208 via anISL having a D_Port state, while an LSSM may be coupled to the switch208 via an ISL having either a D_Port state or an E_Port state dependingon whether the LSSM shares a domain ID with the switch or is assigned adomain ID separate from the domain ID of the switch, respectively.

An intelligent service module that shares the logical domain 214 of thedirector-level switch 208 does not consume additional domain IDs of theSAN and can be managed in-band as an extension of the switch 208 (e.g.,via a D_Port state of the ISL coupling the intelligent service moduleand the switch). Where one or more of the intelligent service modules200, 202, 204, and 206 shares the logical domain 214 of thedirector-level switch 208, the switch 208 is attributed with a domain IDand each domain-sharing intelligent service module is attributed with aunique intelligent service module identifier within the logical domain214 associated with the domain ID. In addition, one or more ports ofeach domain-sharing intelligent service module can be attributed with aunique port identifier within the intelligent service module identifier.In this manner, the management client 212 can uniquely identifydomain-sharing individual intelligent service modules and their portswithin the logical domain 214 of the switch 208 and the switch canhandle some portion of the management requests while forwarding certainmanagement functions to the appropriate intelligent service module forprocessing, when necessary.

Once one of the intelligent service modules shares a domain ID with thedirector-level switch 208 (e.g., as a domain-sharing DSM or LSSM), themodule is no longer a directly hardware-routed destination for domaincontroller frames. It also cannot directly send out domain controllerframes to remote switches because there is no way to route back theresponse. The director-level switch intercepts all domain controllerframes directed to a domain-sharing intelligent service module (e.g., aDSM or domain-sharing LSSM). The switch also intercepts all domaincontroller frames sent to proxy domains it is controlling and assumesthat frames sent to its domain have to be forwarded to DSMs or LSSMssharing its domain. In addition, the switch 208 intercepts all incomingdomain controller frames (including responses) from the DSMs anddomain-sharing LSSMs within it logical domain regardless of thedestination domain ID of the frames. For frames received from thefabric, the director-level switch 208 either responds to the framesdirectly on behalf of one of its associated DSMs or domain-sharing LSSMs(assuming it has the appropriate information cached locally to satisfythe request) or forwards a copy of the message to one or more of theDSMs and domain-sharing LSSMs sharing the same domain ID. If the switch208 forwards a copy of a message requiring a response, it forwards themessage pretending to be the source, collects any responses, and sendsthe response back to the originator on behalf of its domain-sharing DSMsand LSSMs. For frames received from its associated domain-sharing DSMsand LSSMs, the director-level switch 208 intercepts the frames andforwards them to the target destination. The director saves contextinformation in order to route any response back to the correct DSM orLSSM.

Where one or more of the intelligent service modules 200, 202, 204, and206 is configured as a module that does not share the domain ID of theswitch 208 (e.g., via an E_Port state of the ISL coupling the module andthe switch), however, the management client 212 can uniquely identifythe intelligent service module (e.g., an LSSM) by its domain IDindependently of the director-level switch 208. Further, the managementclient 212 may also uniquely identify one or more ports of theintelligent service module via a unique port identifier attributed tothe intelligent service module within the domain ID of the intelligentservice module. Where the intelligent service module shares a proxydomain ID with other devices (e.g., a proxy domain ID shared betweenmultiple LSSMs), the intelligent service module may be assigned a uniqueintelligent service module identifier within the proxy domain ID, andthe unique port identifier(s) of the intelligent service module may belocated within the intelligent service module identifier. The managementclient 212 may thus uniquely identify the intelligent service module andone or more of its ports within the logical domain of the proxy domainID.

In the illustrated implementation, the intelligent service module 200represents a virtualization intelligent service module (VSM) thatprovides Layer 4 SCSI/block storage services. The VSM 200 providesvirtualization services and flexible switch connectivity.

Another intelligent service module 202 in the illustration of FIG. 2represents a routing intelligent service module (RSM) that providesLayer 3 SAN routing services. The RSM 202 provides inter-fabric routingbetween physical and virtual fabrics within the SAN. Yet anotherintelligent service module 204 in FIG. 2 represents a WAN intelligentservice module (WSM) that can provide wide area connectivity, includingiFCP or FCIP bridging, FICON tunneling, and streaming, such as fastwrite, compression, encryption, etc. Further, the intelligent servicemodule 206 in FIG. 2 represents an aggregation intelligent servicemodule (ASM) that aggregates end devices (e.g., host initiators orstorage targets) to the attached switch 208, thereby simplifying thecore-edge topology into a collapsed core that is a logical part of theswitch 208.

FIG. 3 illustrates an exemplary protocol 300 for establishing a physicalconnection between a director-level switch (i.e., the director) and anintelligent services module. In this protocol 300, after an intelligentservice module is connected to the director, the director issues anexchange link parameter (ELP) frame 302. The ELP frame comprisescommunication exchange parameters of the director such as timeout valuesand the like. The intelligent services module receives the ELP frame andassumes the parameters issued by the director. The intelligent servicemodule then issues an ELP_ACCEPT command 304 to the director. TheELP_ACCEPT command, for example, confirms the communication linkparameters back to the director. The director receives the ELP_ACCEPTcommand 304, and confirms that the intelligent service module hasreturned the correct communication link parameters to the director. Ifthe parameters match those of the director, the director continues thecommunication with the intelligent service module; otherwise thedirector severs the communication link and waits for another intelligentservice module to be attached to the fabric.

If the intelligent service module has confirmed the correctcommunication link parameters, however, the director then sends anexchange switch capabilities (ESC) frame 306 back to the intelligentservice module. The ESC frame 306, for example, comprises attributessupported by the particular director. In one variation, for example, theESC frame 306 may comprise domain sharing (D-port), federatedmanagement, leaf master, and/or standard switch capabilities assupported attributes of the director. Of course, the host director maysupport a subset of these attributes and/or additional attributes.

The intelligent service module then determines whether the attributes ofthe module were identified as supported attributes of the director.Where the intelligent service module comprises a director service module(DSM) having D_port protocol and federated management capabilities, forexample, the DSM determines whether the director identified itself asdomain-sharing and federal management capable in the ESC frame 306. Aleaf switch, however, will determine if the director has identifieditself as leaf master capable in the ESC frame 306. In some variations,for example, if the attributes identified by the director in the ESCframe 306 fail to identify a primary capability (e.g., domain-sharingand federated management capable), the intelligent service module maydetermine whether the switch supports a secondary capability alsosupported by the intelligent service module (e.g., a legacy fabricshortest path first (FSPF) routing attribute that determines routes froma switch and implies support for E_Ports and standard routingprotocols). If none of the attributes identified by the director in theESC frame 306 are supported by the intelligent service module, theintelligent service module rejects the ESC frame and the communicationis severed.

If the director supports the predetermined attributes of the intelligentservice module, the module generates an ESC_ACCEPT command 308 and sendsthat command to the director. Where the director identified more thanone attribute in the ESC frame 306, for example, the ESC_ACCEPT command308 may include a client identifier that identifies at least oneattribute of the director that is shared by the intelligent servicemodule. The shared attribute of the switch and the intelligent servicemodule thus determines the communication protocol used for communicationbetween the director and the module.

The director receives the ESC_ACCEPT command 308 and issues a requestclient data command 310 to the intelligent service module. Theintelligent service module then receives the Request Client Data command310 and responds with a Request_Client_Data_Accept command 312. Wherethe intelligent service module has selected domain sharing and federatedmanagement capabilities of the director, for example, the director'srequest client data command 310 may comprise a Request_DSM_Data (RDD)command. The intelligent service module, in turn, issues an RDD_ACCEPTcommand and identifies module data, such as a type of intelligentservice module, a number of ports, and an ownership status. As furtherdiscussed below, the intelligent service module then relinquishescontrol to the federated management of the director.

FIGS. 4A and 4B illustrate a flow diagram of an exemplary method 400 ofestablishing a physical connection between a director-level switch(i.e., the director or host director) and an intelligent servicesmodule. In this example, the intelligent service module and the switchestablish link parameters in the establishing operation 402. Asdescribed above with reference to FIG. 3, the link parameters areestablished by the director sending the intelligent service module anexchange link parameters (ELP) frame, the intelligent service moduleassuming the link parameters received in the ELP frame and sending areply ELP_ACCEPT frame back to the director, and the director confirmingthe link values received in the ELP_ACCEPT frame.

When a DSM is connected to a director-level switch of a SAN, forexample, the DSM and the director are initially in a default state(e.g., “No_HD_Connection” for the DSM and “No_DSM_Connection” for thehost director) that indicate that there are no active or pendingconnections of the DSM and the host director. The DSM and the HD entersthe default state from any other state when all D_Port state ISLconnections are disconnected, when all ports of the DSM revert to theinitial state because the DSM processed a new ELP frame setting new linkparameters, or as part of a SAN online processing sequence. While inthis state, a new connection is detected by the host director and theDSM. The host director and DSM, for example, may use Link Level ELP andESC protocols to detect a new connection between the DSM and the hostdirector. In one configuration, for example, the DSM waits for a hostdirector to initiate link level protocols via an ELP frame, and thedirector initiates communication by issuing the ELP frame. Connectionsbetween the DSM and the director may be established via a uniqueidentifier for each, such as a WWN. When a new connection between theDSM and the director is detected, the DSM and the director enter newstates (e.g., a “New_HD_Connection” state for the DSM and aNew_DSM_Detected state for the host director). Similar connection statescould also be used for an LSSM or even a standard switch connecting tothe director.

Once the intelligent service module and the director have detected eachother and established link parameters via the ELP and ELP_ACCEPT frames,the intelligent service module and the director negotiateresponsibilities for the module and the director in the negotiatingoperation 404. As described above with reference to FIG. 3, theresponsibilities can be negotiated between the intelligent servicemodule and the director via an ESC frame issued by the director and anESC_ACCEPT frame returned from the intelligent service module. The ESCframe indicates the attributes supported by the director (e.g., viaattribute flags of the ESC frame). Thus, when the intelligent servicemodule receives this frame, the module first determines whether thedirector is capable of supporting it. If the director is not capable ofsupporting the particular type of intelligent service module, the modulemay reject the ESC frame prompting the director to sever thecommunication. If the director is capable of supporting the intelligentservice module, however, the module responds with an ESC_ACCEPT framethat identifies which attributes of the director that are required tosupport the module.

In one configuration, for example, the ESC frame of the director mayinclude attribute flags identifying at least one of the followingattributes: (1) Federated Management, (2) Leaf Routing, (3) Domain IDSharing, and (4) Server/Provider. Where an intelligent service moduleconfigured as a DSM is connecting to the director, for example, the ESCframe issued by the director may include flags identifying all or aportion of the supported attributes (such as those listed above), andthe DSM would respond with an ESC_ACCEPT frame identifying itself as aClient and further including supported attribute flags such as FederatedManagement, Domain ID Sharing, and Leaf Routing. An intelligent servicemodule configured as an LSSM, however, may receive the same ESC frameand respond, in addition to identifying itself as a Client, withattribute flags identifying support attributes such as Leaf Routing andDomain ID Sharing for a domain sharing LSSM or a Leaf Routing supportattribute for a non-domain sharing LSSM. If a regular switch isconnected to the director, however, the switch would only respond withattribute flags selecting a standard routing protocol (e.g., an FSPFrouting protocol). If the ESC frame issued by the director does notprovide an attribute required by the configuration of the intelligentservice module, however, the module may reject the ESC frame promptingthe director to sever the communication.

After the intelligent service module and the director have negotiatedresponsibilities between them in the negotiating operation 404, thedirector may initiate an authentication challenge to the DSM inauthenticating operation 405. In one configuration, for example, D_Portscan only be authenticated if the DSM has been configured withauthentication secrets from a prior connection. For new DSM connections,however, user acceptance may be required as an alternative to anauthentication challenge.

After the director has successfully authenticated the intelligentservice module in the authenticating operation 405, the directordetermines the type of the intelligent service module connected to thedirector (e.g., a DSM, a domain-sharing LSSM, or a standard switchconnection) in a determining operation 406. If the module is a DSM, forexample, the method 400 proceeds to determining operation 408, where thedirector then determines the type of DSM. For example, the director maysend a request to the new DSM for its identification data.

The director then begins the process of establishing federatedmanagement over the DSM. As part of this process of establishingfederated management, the director first determines the ownership statusof the DSM in a determining operation 410. If the DSM is actively ownedby another director, for example, the attempt to establish a connectionbetween the director and the DSM is rejected in operation 412 and theprocess of connecting the DSM to the director terminates. If the DSM isactively or previously owned by the current director, however, theattempt to establish the connection continues, and the method proceedsto setting operation 418, discussed below. If the DSM is un-owned orpreviously owned by another director, the process proceeds to queryingoperation 414 to query a user (e.g., via the management client) forpermission to take ownership of the DSM. This provides a securityoperation to prevent an unauthorized DSM from being installed on the SANwithout permission. If permission to establish federated management overthe DSM is denied by the user, the method branches in a determiningoperation 416 to the rejecting operation 412 and the process ofconnecting the DSM to the director terminates. If the determiningoperation 416 determines that permission was granted for the director toestablish federated management over the DSM, however, the methodbranches to setting operation 418.

In the setting operation 418, an in-band IP address for the DSM is setby the director. In this operation, for example, the director sends acommand (e.g., a Set_IP_Address_ILS command) to the DSM and waits for aresponse. If the DSM accepts the command, it indicates that the directorhas established ownership over the DSM and is ready to establish afederated management TCP/IP connection. If the DSM rejects the command(e.g., where another director was faster with its request to claimownership of the DSM), however, the director will transition back to theNew_DSM_Detected state, described above with respect to establishingoperation 402, to attempt to start the process over. If the attempt toset the IP address of the DSM fails multiple times over all availableports, the director may transition to a failed state (e.g., aDSM_Connection_Failed state).

After the director has successfully set the IP address of the DSM, themethod proceeds to a configuring operation 419 in which FederatedManagement of the DSM is established and used to configure the DSM. Inthe configuring operation 419, the director uses the IP address toestablish a federated management TCP/IP connection path, configures theDSM, and notifies the management client fabric services when the processhas been completed. Then, in the address distribution operation 420, thestate will transition to a control state (e.g., aFabric_Services_Control state) and the director will take control of theDSM to establish domain sharing with the DSM by completing theconnection of the DSM to the director via the D_Port state of the ISLconnection. In the control state, the fabric services will complete allrequired Fabric Services protocols, such as a fabric initializationprocess used to assign domain and area IDs to the DSM and a zoningprocess for the fabric. Once the fabric services processes are complete,the DSM is activated and host/module operation is initiated inAsymmetrical Fabric Services operation 422.

Once the Asymmetrical Fabric Services operation 422 executes to completefabric initialization between the director and the DSM, the DSM willwait until it receives an Activate message from the director inactivating operation 424 before becoming fully functional in operation426 in a DSM D_Port configuration.

With the DSM model of sharing a domain ID across multiple switches, thedirector incurs an extra burden to synchronize and coordinate activitiesamongst the attached DSMs—not only through Federated Management, butalso through the Fabric Services. Once the Activate message is receivedby the DSM, the DSM retrieves additional information from the rest ofthe fabric before allowing devices—either external devices or, in thecase of VSM, internal virtualization devices—to login. The fabricsynchronization of this information, along with the subsequent devicelogin, can place a burden on the director if not throttled to somedegree. The Activate message allows the Fabric Services on the directorto control and smooth out this burden to ensure better performance andmore predictable, stable fabric behavior. The Activate message is sentto the DSM via Federated Management, but is controlled by the FabricServices.

In a standard Fibre Channel fabric, for example, two switches act asindependent entities that communicate with standardized protocols. Theidea of one switch “Activating” another is unique and fits well with theclient-server model of the DSM architecture.

If the intelligent service module is determined to be a domain-sharingleaf switch in determining operation 406, the method proceeds to addressdistribution operation 428 (which is similar to the address distributionoperation 420 described above), Asymmetrical Fabric Services operation430 (which is similar to Asymmetrical Fabric Services operation 422described above), and then becomes functional in operation 432 in astandard switch D_Port configuration.

If the intelligent service module is determined to be a standard switchconnection in operation 406, however, the method proceeds to standardaddress distribution operation 434, to standard fabric servicesoperation 436, and then becomes functional in operation 438 in astandard switch E_Port configuration.

Federated Management provides the capability to manage at least one DSMattached to a director as if the DSM was logically part of the director.This capability is achieved by software and firmware that makes use ofin-band links between the director and the DSM for communication.Further details of Federated Management are described in U.S. patentapplication Ser. No. 11/239,954 entitled “Federated Management ofIntelligent Service Modules” and filed on Sep. 29, 2005 by JosephChamdani et al., which is incorporated by reference herein in itsentirety.

The embodiments of the invention described herein are implemented aslogical steps in one or more computer systems. The logical operations ofthe present invention are implemented (1) as a sequence ofprocessor-implemented steps executing in one or more computer systemsand (2) as interconnected machine or circuit modules within one or morecomputer systems. The implementation is a matter of choice, dependent onthe performance requirements of the computer system implementing theinvention. Accordingly, the logical operations making up the embodimentsof the invention described herein are referred to variously asoperations, steps, objects, or modules. Furthermore, it should beunderstood that logical operations may be performed in any order, unlessexplicitly claimed otherwise or a specific order is inherentlynecessitated by the claim language.

The above specification, examples and data provide a completedescription of the structure and use of exemplary embodiments of theinvention. Since many embodiments of the invention can be made withoutdeparting from the spirit and scope of the invention, the inventionresides in the claims hereinafter appended. Furthermore, structuralfeatures of the different embodiments may be combined in yet anotherembodiment without departing from the recited claims.

What is claimed is:
 1. A system comprising: a switch module configuredfor connection to an intelligent service module that initiates anestablishment of at least one link parameter at the intelligent servicemodule and initiates a negotiation of responsibilities of a switchcontaining the switch module and the intelligent service module byissuing at least one attribute for provision to the intelligent servicemodule; wherein the switch module includes a processor, firmware, acircuit module, or a storage media.
 2. The system of claim 1 wherein theswitch module initiates the negotiation of responsibilities by issuingan ESC frame comprising the least one attribute.
 3. The system of claim2 wherein the switch module receives an ESC_ACCEPT frame confirming theat least one attribute of the intelligent service module.
 4. The systemof claim 1 wherein the switch module initiates the establishment of linkparameters by issuing an ELP frame and receives an ELP_ACCEPT frameconfirming the link parameters.
 5. The system of claim 1 wherein theconnection comprises a Fibre Channel connection.
 6. The system of claim1 wherein connection comprises an Ethernet communication connection. 7.The system of claim 1 wherein the at least one attribute comprises afederated management capable attribute.
 8. The system of claim 1 whereinthe at least one attribute comprises a domain-sharing capable attribute.9. A system comprising: an intelligent service module configured forconnection to a switch module that receives a request to initiate anestablishment of at least one link parameter and receives a request toinitiate a negotiation of responsibilities of a switch containing theswitch module by receiving at least one attribute; wherein theintelligent service module includes a processor, firmware, a circuitmodule, or a storage media.
 10. The system of claim 9 wherein theintelligent service module receives an ESC frame comprising the leastone attribute to initiate the negotiation of responsibilities.
 11. Thesystem of claim 10 wherein the intelligent service module confirms theat least one attribute by issuing an ESC_ACCEPT frame confirming the atleast one attribute.
 12. The system of claim 9 wherein the intelligentservice module receives an ELP frame to initiate the establishment oflink parameters and confirms the link parameters by issuing anELP_ACCEPT frame.
 13. The system of claim 9 wherein the connectioncomprises a Fibre Channel connection.
 14. The system of claim 9 whereinconnection comprises an Ethernet communication connection.
 15. Thesystem of claim 9 wherein the at least one attribute comprises afederated management capable attribute.
 16. The system of claim 9wherein the at least one attribute comprises a domain-sharing capableattribute.
 17. The system of claim 9 wherein the intelligent servicemodule assumes the link parameters of the switch.
 18. A systemcomprising: an intelligent service module; and a connected to theintelligent service module, wherein the switch module initiates anestablishment of at least one link parameter at the intelligent servicemodule and initiates a negotiation of responsibilities of a switchcontaining the switch module and the intelligent service module byissuing at least one attribute for provision to the intelligent servicemodule, wherein the intelligent service module receives a request toinitiate an establishment of at least one link parameter from the switchmodule and receives a request to initiate a negotiation ofresponsibilities of a switch containing the switch module from theswitch module by receiving at least one attribute, wherein the switchmodule includes a processor, firmware, a circuit module, or a storagemedia, and the intelligent service module includes a processor,firmware, a circuit module, or a storage media.
 19. The system of claim18 wherein the switch module initiates the negotiation ofresponsibilities by issuing an ESC frame comprising the least oneattribute and wherein intelligent service module receives the ESC framecomprising the least one attribute to initiate the negotiation ofresponsibilities.
 20. The system of claim 19 wherein the intelligentservice module confirms the at least one attribute by issuing anESC_ACCEPT frame confirming the at least one attribute, and wherein theswitch module receives the ESC_ACCEPT frame confirming the at least oneattribute of the intelligent service module.
 21. The system of claim 18wherein the switch module initiates the establishment of link parametersby issuing an ELP frame and receives an ELP_ACCEPT frame confirming thelink parameters, and wherein the intelligent service module receives theELP frame to initiate the establishment of link parameters and confirmsthe link parameters by issuing the ELP_ACCEPT frame.
 22. The system ofclaim 18 wherein the connection comprises a Fibre Channel connection.23. The system of claim 18 wherein connection comprises an Ethernetcommunication connection.
 24. The system of claim 18 wherein the atleast one attribute comprises a federated management capable attribute.25. The system of claim 18 wherein the at least one attribute comprisesa domain-sharing capable attribute.
 26. The system of claim 18 whereinthe intelligent service module assumes the link parameters of theswitch.